home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / ospf / ospf-minutes-92jul.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  176 lines

  1.  
  2. Editor's Note:  Minutes received 7/31
  3.  
  4. CURRENT_MEETING_REPORT_
  5.  
  6.  
  7. Reported by John Moy/Proteon
  8.  
  9. Minutes of the Open Shortest Path First IGP Working Group (OSPF)
  10.  
  11. The OSPF Working Group met at the July 1992 IETF in Boston.  The Minutes
  12. from that meeting follow.
  13.  
  14. The meeting began with a review of the four documents that are currently
  15. be considered for publication by the Working Group:
  16.  
  17.  
  18.   1. The updated OSPF V2 specification.  This will supersede RFC 1247.
  19.      Unfortunately, the document was not available prior to the meeting.
  20.      (A limited number of paper copies of the updated specification were
  21.      made available to implementors, and the specification was made
  22.      available for anonymous ftp after the meeting.)  An excerpt from
  23.      the document briefly detailing the changes was handed out, and the
  24.      changes (all backward- compatible) were discussed.  It was also
  25.      decided to make one additional change:  it will now be possible to
  26.      specify a set of area address ranges that will not be advertised in
  27.      summary-LSAs.  This will enable a network administrator to hide
  28.      certain networks within their local areas.  This change has already
  29.      been implemented by some vendors.
  30.   2. The updated OSPF V2 MIB. This will supersede RFC1253.  Fred Baker
  31.      outlined the proposed changes.  It was also decided to make
  32.      additions for the multicast routing extensions and the new NSSA
  33.      area option.  An addition to the Area Range Group was also made for
  34.      the above ``hidden network'' feature.  An additional request for a
  35.      network mask in the new external-LSA table entries was not acted
  36.      upon.
  37.   3. The OSPF Trap MIB. Rob Coltun led the discussion.  There was some
  38.      question whether an additional error code should be added for
  39.      receiving Illegal-LSAs.  It was decided that this would probably
  40.      already show up as retransmissions by the faulty sender, and as
  41.      such was unnecessary.  It was also decided to have the
  42.      ospfLsdbApproachingOverflow trap occur at a configurable database
  43.      size, instead of 90 percent of the maximum (as stated in the
  44.      draft).
  45.   4. The OSPF NSSA option.  Rob Coltun spent some time explaining how
  46.      they work, spending time on the translation between type-7 and
  47.      type-5 LSAs, and how you could distinguish a ``local'' type-7
  48.      default from one that can be translated into a global type-5
  49.      default.  No changes were made to this document.
  50.  
  51.  
  52. Osmund deSouza presented a proposal for running OSPF over Frame relay.
  53. There was general agreement on the problem:  Frame relay is in general
  54. not full-mesh connected, and the network administrator sometimes wants
  55. to assign different costs to different PVCs.  For these reasons, OSPF's
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63. non-broadcast model is not directly applicable.  There was also general
  64. agreement on the solution:  instead of treating the connection to Frame
  65. relay as a single OSPF interface, define an OSPF interface as some
  66. collection of PVCs.  There was a long discussion of how to represent
  67. this in terms of MIB II and the OSPF MIB. It was decided that Osmund et.
  68. al., with the help of Fred Baker, would rewrite their present document
  69. more along the lines of a usage document.  With this document in hand,
  70. it would be hoped that equipment from different vendors would be able to
  71. interoperate using OSPF over Frame relay.
  72.  
  73. John Moy presented an alternative model for running OSPF over Frame
  74. relay, where there would be a single interface to the frame relay net
  75. and a) neighbors would be discovered dynamically using Inverse ARP b)
  76. OSPF Hellos would be used to build a spanning tree among Frame relay
  77. connected routers, for purpose of update distribution (database
  78. synchronization) c) by default, only these spanning tree links
  79. (adjacencies) would be included in router-LSAs and d) to get better
  80. routing across the Frame relay, more PVCs could be included in the
  81. router-LSAs or (not as good) a variant of short-cut routing could be
  82. used.  John's main reason for preferring this approach is that it didn't
  83. need a human to configure it, and that it was optimal in terms of
  84. routing traffic.  This proposal was not generally well received, being
  85. characterized as either too complicated or too different than current
  86. practice.  John said that he would write it up anyway if he had the
  87. time.
  88.  
  89. John Moy presented a proposal for dealing with OSPF Database Overflow.
  90. In this proposal, only the number of type-5 LSAs would be limited.  The
  91. reasoning being that these constitute a majority of the database in
  92. places like the NSF regionals.  A limit for the number of these LSAs
  93. would be set identically in each of these routers, either via SNMP or
  94. negotiated in a new LSA type or in OSPF Hellos.  Then, when the limit is
  95. reached in a router it a) won't accept any more and b) will flush all
  96. its self-originated type-5 LSAs, refusing to originate any more.  The
  97. claim is that this logic produces an identical database in all routers,
  98. with less than the configured maximum number of type 5 LSAs, no
  99. continual retransmissions, and all internal routing intact.
  100. Enhancements to this scheme could involve limiting other LSA types
  101. (e.g., summaries), and to begin again to originate type-5 LSAs after a
  102. random time lag to automatically deal with temporary overflow.
  103.  
  104. John said that a similar scheme has been used in Proteon routers for
  105. several years.  The proposal was characterized by some Working Group
  106. members as being like congestion control, and some desire for an
  107. additional congestion-avoidance-like mechanism was expressed.  Some
  108. people also requested a way to prioritize the order in which excess
  109. advertisements are flushed (e.g., you might want to flush the default
  110. routes last).  John promised to sort through the enhancements and
  111. publish a coherent Internet Draft.
  112.  
  113. Rob Coltun ended the meeting with a quick discussion on how hierarchical
  114. routing information might be injected into OSPF, in order to support any
  115. of the schemes for IPV7.
  116.  
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Attendees
  125.  
  126. J. Allard                jallard@microsoft.com
  127. William Babson           bill@penril.com
  128. Dennis Baker             dbaker@wellfleet.com
  129. Fred Baker               fbaker@acc.com
  130. John Ballard             jballard@microsoft.com
  131. Ken Benstead             kbenstead@coral.com
  132. Geetha Brown             geetha@decvax.dec.com
  133. Steve Buchko             stevebu@newbridge.com
  134. Greg Celmainis           gregc@newbridge.com
  135. Frank Chen               frankc@casc.com
  136. Dean Cheng               dean@sun2.retix.com
  137. Robert Ching             natadm!rching@uunet.uu.net
  138. Chris Chiotasso          chris@artel.com
  139. Henry Clark              henryc@oar.net
  140. Rob Coltun               rcoltun@ni.umd.edu
  141. Jim Comen                comenj@interlan.interlan.com
  142. Michael Davison          davison@cs.utk.edu
  143. Osmund de Souza          osmund.desouza@att.com
  144. Dino Farinacci           dino@cisco.com
  145. AnneMarie Freitas        afreitas@microcom.com
  146. Vince Fuller             vaf@stanford.edu
  147. Kelly Furlong            kelly@kyle.ksc.nasa.gov
  148. Der-Hwa Gan              dhg@nsd.3com.com
  149. Ian Heavens              ian@spider.co.uk
  150. Jeffrey Honig            jch@nr-tech.cit.cornell.edu
  151. Steven Hubert            hubert@cac.washington.edu
  152. Ronald Jacoby            rj@sgi.com
  153. Dwight Jamieson          djamies@bnr.ca
  154. Dan Jordt                danj@nwnet.net
  155. John Krawczyk            jkrawczy@wellfleet.com
  156. Alan Kullberg            akullber@bbn.com
  157. Whay Lee                 whay@merlin.dev.cdx.mot.com
  158. Anthony Lisotta          lisotta@nas.nasa.gov
  159. Robin Littlefield        rlittlef@wellfleet.com
  160. John Moy                 jmoy@proteon.com
  161. Erik Nordmark            nordmark@eng.sun.com
  162. Benny Rodrig             4373580@mcimail.com
  163. Manoel Rodrigues         manoel_rodrigues@att.com
  164. Henry Sanders            henrysa@microsoft.com
  165. Hellen Sears             sears@interlan.interlan.com
  166. Martha Steenstrup        msteenst@bbn.com
  167. Linda Tom                toml@interlan.interlan.com
  168. Kannan Varadhan          kannan@oar.net
  169. Scott Wasson             sgwasson@eng.xyplex.com
  170. Luanne Waul              luanne@wwtc.timeplex.com
  171. Honda Wu                 natadm!honda@uunet.uu.net
  172.  
  173.  
  174.  
  175.                                    3
  176.